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PROTECTED MECHANISM FOR DTMF RELAY 

BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

The present invention generally relates to communication over a packet network and, 
more particularly, to processing and generating DTMF signals in the packet network. 

2. RELATED ART 

The packetizing of voice signals for transmission over a packet network, (i.e.. Voice 
over Packet or "VoP"), has been recognized as a less expensive, yet effective, alternative to 
traditional telephone service. The term VoP is an umbrella term that can include, for example, 
VoIP, VoATM, VoDSL and other types of services utilizing packetized voice data. 

Referring to FIG. 1 A, conventional communication system 100 is used to illustrate the 
architecture and operation of a typical VoP network. As shown, communication system 100 
comprises calling device 102, which can be an analog telephone, for example. An analog 
voice signal from calUng device 102, generated by a client speaking into the device's 
microphone, for example, travels over copper wires (i.e., the local loop) to central office 104, 
where the analog voice signal can be digitized using a conversion standard, such as G.711. 
The digitized voice signal is then transmitted over public switched telephone network 
C'PSTN") 106 to gateway 108. 

At gateway 108, which is situated on the emitting side of packet network 110, for 
purposes of the present illustration, the digitized voice signal is compressed and packetized for 
transmission over packet network 110. The compression of the speech signal at gateway 108 
can be performed by a low-rate voice codec such as, for example, either G.723 or G.729, thus 
reducing the amount of data that has to be packetized and sent over packet network 110 to 
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receiving device 112. Receiving device 112 can be, for example, a gateway or application 
server configured to receive and process packets fi"om packet network 110. For example, 
receiving device 112 may depacketize and decompress the voice signal carried by the packets 
arriving fi-om packet network 110. The voice signal can then be relayed to another central 
office, for example, and eventually to the called party. 

One challenge facing the telecommunications industry is the effective processing of 
dual-tone multifrequency ("DTMF") signals in a packet architecture. DTMF tones refer to 
the tones generated by pressing the buttons (i.e., the digits) on the keypad of a touch-tone 
telephone, which typically has twelve digits (i.e., numbers 1-9, the asterisk and the pound 
sign In some cases, buttons having letters A, B, C, or D may also be found on certain 
telephone models, bringing the total numbers of buttons on such telephones to sixteen. Each 
button on a telephone's keypad is assigned a specific and distinct tone produced by the 
combination of two tones of different frequencies. For example, digit "1" is composed of 
1200 Hz and 697 Hz tone pair, digit is composed of 1477 Hz and 941 Hz tone pair, and 
digit "B" is composed of 1633 Hz and 770 Hz tone pair. Manifestly, sixteen frequency or 
tone pairs have been designated and reserved to represent the sixteen DTMF digits. DTMF 
digits can be specified as named telephony events, or "NTE." Alternatively, the fi'equencies 
and levels of the tones can be specified directly as telephony tones, or "TT." 

The uniqueness of the tones associated with the DTMF digits is exploited for general 
signaling purposes, such as when dialing a particular telephone number. DTMF tones are also 
commonly utilized as a means for selecting specific items fi*om a menu, for example, or for 
accessing specific apphcations offered by an application server during a "voice" call. By way 
of illustration, a caller dialing into a governmental agency, for instance, may be routed through 
a series of steps whereby each step is initiated by the caller entering the appropriate digit in 
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order to arrive at a desired destination, service, application or the like. In order for this 
process to proceed properly and effectively, the receiving device at the governmental agency 
must be able to detect and recognize accurately the digits entered by the caller. 

Moreover, specific standards have been implemented setting forth the requirements for 
DTMF detection. Such criteria as tone duration, tone separation and frequency deviation 
each must satisfy certain boundaries before a receiving device will recognize, or accept, a 
signal as a legitimate DTMF digit. For example, the duration of a tone must last for at least 
40 msec before a DTMF digit is recognized. Also, the minimum interdigital interval (i.e., the 
"silence" period between two tones) must last for at least 40 msec in order for the receiving 
device to detect the presence of two separate DTMF digits; otherwise, the trailing tone may 
be discarded or treated as part of the leading tone. Requirements for the detection of DTMF 
digits can be foiand, for example, in standards promulgated by the Electronic Industries 
Alliance/Telecommunications Industry Association ("EIA/TIA") and the International 
Telecommunication Union-Telecommunication Standards Sector ("ITU-T"). 

As described above, voice signals can be compressed at gateway 108, for example, 
using low-rate voice codecs such as G.723 or G.729 for more efficient transmission of voice 
data across a packet network. However, these speech compression standards have proven to 
be unsatisfactory for proper handling of DTMF tones. More specifically, when subjected to 
the same type of compression as voice signals, DTMF tones are often unacceptably distorted. 
As a consequence, the tones generated and packetized by the transmitting gateway can be 
inaccurate, leading to poor detection and recognition by a receiving device on the other side 
of the packet network. 

In order to improve DTMF relay across a packet network, DTMF digits may be 
processed at the gateway independently of the voice signal, even when both are received from 
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the same device. As such, the DTMF tones do not have to undergo the same type of 
compression as the voice signal. One format for packetizing DTMF digits independently of 
voice signals for transmission across a packet netv^ork is the Internet Engineering Task 
Force's CIETF") Request For Comment 2833 ("RFC2833"), 

Reference is now made to FIG. IB, which illustrates an example of an RFC2833-type 
packet for transporting DTMF digits. As shown, packet 140 is transporting three DTMF 
tones, i.e., DTMF tones 142, 144 and 146, which code DTMF digits 9, 1 and 1, respectively. 
The on/off status of a tone is indicated by its associated end or "E" bit. For example, E bit 
160 for DTMF tone 142 is set to 1, which means that DTMF tone 142 is off, while E bit 162 
for DTMF tone 146 is set to 0, which means that DTMF tone 146 is on. The duration of each 
tone is coded in its duration field. For example, DTMF tone 142 had a duration of 1600 
timestamp units as indicated by duration field 150, while DTMF tone 144 had a duration of 
2000 timestamp units as indicated by duration field 152. DTMF tone 146 (which is still on 
based on the setting of its E bit), has been on for 400 timestamp units as indicated by duration 
field 154. Timestamp field 148 indicates that the last event being transported by packet 140 
(i.e., DTMF tone 146), was pressed or entered by the calling party at time 11200 (in 
timestamp units), assuming that the first tone carried by packet 140 (i.e., DTMF tone 142) 
was entered at time 0. Timestamp offset fields 156 and 158 are used to code the length of 
time since DTMF tone 142 and DTMF tone 144, respectively, were first detected by the 
emitting device. 

Although RFC2833 provides an effective means for packetizing DTMF digits by the 
device on the emitting side of a packet network, serious issues and drawbacks remain with the 
processing of such packets on the receiving side of the packet network. For example, due to 
packet loss and other deficiencies associated with packet networks, the device responsible for 
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processing DTMF digits on the receiving side of the packet network may not receive all the 
packets needed to regenerate the digits reliably. Such a case may arise, for example, when 
end-of-event packets signaling that a tone has ended are lost, in which case the receiving 
device may end up regenerating a digit for an indefinite length of time. As another example, 
start-of-tone packets may be lost, resulting in improper initiation of tone regeneration by the 
receiving device. 

By way of illustration of how packet loss can impact reUable DTMF relay, consider a 
scenario involving the following six packets: (1) packet A indicates that a first tone has 
started; (2) packet B is a keep-alive packet for the first tone; (3) packet C indicates that the 
first tone has finished; (4) packet D indicates that a second tone has started; (5) packet E is a 
keep-alive packet for the second tone; and (6) packet F indicates that the second tone has 
finished. In this scenario, the time period between the transmission of packet A and packet C 
is suflScient for a receiving device to detect the DTMF digit. However, the period between 
the transmission of packets B and C is not sufficiently long for proper detection. Thus, if 
packet A is lost, the receiving device would detect packet B as the start of the first tone and 
would end the first tone with packet C, and the duration of the regenerated tone would not be 
long enough to be valid. As another example, when packet C is lost, the tone starts with 
packet A but would not end until packet D is received. But because packet D indicates the 
start of a second tone, the second tone would be regenerated immediately following cessation 
of the first tone. In such case, there is an insufficient off time between the first tone and the 
second tone, and the DTMF sequence would be considered invaUd. 

Currently known schemes directed to transmitting DTMF digits across a packet 
network reliably have proven inadequate in several respects. For example, one known scheme 
involves retransmitting packets as ofl;en as necessary to compensate for lost packets. 
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However, such an approach introduces unacceptably long delays into the system since time 
has to be allotted for receipt acknowledgement and possible re-transmission. Furthermore, 
since real-time voice transport seldom uses error correction, a DTMF relay scheme which 
relies on retransmission and error correction may need a separate transport layer from that 
used for voice transmission, thus adding implementation complexity. Other approaches may 
involve using different redundancy schemes to alleviate the impact of packet loss. As a 
general point, however, the requirements for accurate DTMF relay as applied to VoP under 
present standards and proposals are not adequately addressed. 

Thus, there is an intense need in the art for an improved approach to DTMF 
processing over packet networks that can overcome the shortcomings of the existing designs 
and can provide a more reliable and accurate detection and recognition of DTMF digits. 
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SUMMARY OF THE INVENTION 

In accordance with the purpose of the present invention as broadly described herein, 
there is provided methods and devices for relaying tone events in a communication system. In 
one aspect of the invention, a first tone data indicative of a first tone is received by a receiver 
element and buflFered in a memory element. Following, a second tone data indicative of a 
second tone is received and buffered in the memory element. The first and second tones can 
be, for example, DTMF digits. A processor next retrieves the first tone data firom the memory 
element and generates the first tone corresponding to the first tone data. Using a timer 
element, for example, the processor generates the first tone for at least a first predetermined 
period, which can be approximately 50 msec, for example. Afl;er the first tone has ended, the 
processor waits for a second predetermined period before retrieving the second tone data 
fi-om the bujffer. The second predetermined period can be, for example, 50 msec. 
Subsequently, the processor generates the second tone corresponding to the second tone data 
for at least the first predetermined period of time. In one aspect, the second tone can be 
generated until an end of tone data is received. 

In another aspect, a first tone data and a first tone duration are received, where the 
first tone date is indicative of a first tone, the first tone data is then buflFered and retrieved, and 
the first tone corresponding to the first tone data is generated. A first timer set to a first 
predetermined period is started when the first tone starts being generated. For example, the 
first predetermined period can be 200 msec. Thereafl:er, the first timer is restarted when a 
keep-alive data for the first tone is received, in which case the first tone continues to be 
generated. Otherwise, the first tone is stopped when the first timer expires. In one aspect, 
when a second tone data indicative of a second tone is received prior to the first tone ending, 
an elapsed time since the first tone began is determined. Next, the first tone is stopped when 
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the elapsed time exceeds a second predetermined period, which can be, for example, 50 msec. 
A third predetermined period is then allowed to pass before the second tone corresponding to 
the second tone data is generated. 

In a further aspect a first tone data and a first tone duration are received, where the 
first tone date is indicative of a first tone, and the first tone data is buffered. Also, a second 
tone data and a second tone duration are received, where the second tone date is indicative of 
a second tone, and the second tone data is stored in the buffer. A fixed tone period and a 
fixed silence period are provided, which are independent of the first tone duration and the 
second tone duration. The first tone data is retrieved from the buffer and the first tone 
corresponding to the first tone data is generated for the fixed tone period. Next, the second 
tone data is retrieved fi*om the buffer and, after waiting for the fixed silence period, the second 
tone corresponding to the second tone data is generated for the fixed tone period 

These and other aspects of the present invention will become apparent with further 
reference to the drawings and specification, which follow. It is intended that all such 
additional systems, methods, features and advantages be included within this description, be 
vdthin the scope of the present invention, and be protected by the accompanying claims. 
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BRIEF DESCRIPTION OF DRAWINGS 

The features and advantages of the present invention will become more readily 
apparent to those ordinarily skilled in the art after reviewing the following detailed description 
and accompanying drawings, wherein: 

FIG. lA illustrates a conventional communication system for communicating voice 
over packet network; 

FIG. IB illustrates a conventional RFC2833-type packet for transporting DTMF 

digits; 

FIG. 2 illustrates a DTMF relay system for processing and generating DTMF signals 
according to one embodiment of the present invention; and 

FIG. 3 illustrates an exemplary flow diagram of a communication method utilizing the 
DTMF relay system of FIG. 2. 
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DESCRIPTION OF EXEMPLARY EMBODIMENTS 
The present invention may be described herein in terms of functional block 
components and various processing steps. It should be appreciated that such functional 
blocks may be realized by any number of hardware components and/or software components 
configured to perform the specified functions. For example, the present invention may employ 
various integrated circuit components, e.g., memory elements, digital signal processing 
elements, logic elements, and the like, which may carry out a variety of functions under the 
control of one or more microprocessors or other control devices. Further, it should be noted 
that the present invention may employ any number of conventional techniques for data 
transmission, signaling, signal processing and conditioning, tone generation and detection and 
the like. Such general techniques that may be known to those skilled in the art are not 
described in detail herein. It should be appreciated that the particular implementations shown 
and described herein are merely exemplary and are not intended to limit the scope of the 
present invention in any way. 

FIG. 2 illustrates exemplary DTMF relay system 200 for processing and generating 
DTMF signals, according to one embodiment of the present invention. As shown, DTMF 
relay system 200 includes dual tone multi-frequency ("DTMF") relay module 206, which is 
situated at the receiving side of packet network 202, and which is configured to receive NTE 
packets 204 from packet network 202. DTMF relay module 206 can be, for example, part of 
a remote access server, a media gateway or other end equipment that receives and processes 
packetized data. Packet network 202 can be the Internet or other packet-based networks 
across which NTE's, such as DTMF and other tone signals, may be transmitted utilizing 
suitable packet formats. For example, NTE payloads may be packetized by a gateway (not 
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shown) at the emitting side of packet network 202 and sent across packet network 202 to 
DTMF relay module 206 in accordance with the IETF format RFC2833, as discussed above. 

In the present embodiment, packets from packet network 202 containing NTE 
payloads are processed by DTMF relay module 206. DTMF relay module 206 can be 
configured to determine which of the incoming packets are carrying DTMF digits and to 
regenerate DTMF digits, when they are detected, for transmission to a receiving device (not 
shown) such that enhanced DTMF detection and recognition by the receiving device are 
achieved. For example, DTMF relay module 206 may regenerate DTMF digits by suitably 
creating tones in a manner that meets the requirements of the EIA/TIA and ITU-T 
specifications for DTMF detection. 

As shown in FIG. 2, DTMF relay module 206 comprises keep-alive timer 208, 
processor 210, tone on/off clock 212, protected buffer 214 and tone regenerating module 216. 
NTE packets 204 arriving from packet network 202 may be initially received by processor 
210, which can be configured to analyze the contents of each of such incoming packets in 
order to determine whether a packet is carrying a DTMF digit. According to the RFC2833 
format, for example, the particular NTE payload of a packet is indicated in the packet's event 
field. More specifically, digits zero through fifteen have been reserved for the sixteen DTMF 
digits, whereby each reserved digit corresponds to a particular DTMF tone. Thus, based on 
the information contained in the packet, processor 210 can determine whether the packet is 
carrying a DTMF digit or some other NTE, as well as which particular DTMF digit is being 
transported by the packet. Packets carrying DTMF payloads are subject to further processing 
by processor 210, while processing of non-DTMF packets may cease. 

Processor 210 can also be configured to determine the on/ofF status of a DTMF digit 
carried by an incoming packet based on the information contained in the packet. As discussed 
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above, the on/off status of a DTMF tone is indicated by the end, or "E", bit in the packet, 
which is set by the device responsible for packetizing the digit (e.g., an emitting gateway). An 
end bit set to the value of"!", for example, indicates that the tone is off and signifies an "end- 
of-event" packet. On the other hand, an end bit set to "0" indicates that the payload in the 
5 packet is either new, or else that the packet is a "keep-alive" packet, depending on, for 
example, the packet's timestamp. Keep-alive packets refer to those packets that carry DTMF 
digits that already have an on status. It is noted that RFC2833 permits packetizing more than 
one NTE per packet, in which case processor 210 may identify the specific character of each 

M; NTE in the packet from its corresponding event field and may further identify the on/ofF status 

O 10 of each detected DTMF digit, if any, from its associated end bit. 

fZ In instances where processor 210 detects that a received packet is carrying a DTMF 

digit, processor 210 can derive additional data from the packet in order to determine whether 
Q it is desirable for the DTMF digit to be regenerated. The process involved in making this 

fy determination is described in greater detail below in relation to FIG. 3. Once processor 210 

O .15 determines that a detected DTMF digit should be regenerated, processor 210 checks to 

m 

determine whether protected buffer 214 is Ml In one embodiment, if protected buffer 214 
has space available, the DTMF digit is queued in protected buffer 214; otherwise, the DTMF 
digit may be dropped. Protected buffer 214 can be a memory element wherein DTMF digits 
may be sequentially queued and, when appropriate, sent to tone regenerating module 216 to 
20 be regenerated. Tone regenerating module 216 can regenerate a digit by recreating its tonal 
representation in a suitable manner known in the art. Digits regenerated by tone regenerating 
module 216 (i.e., regenerated tones 218) can then be sent to the receiving device. 

Continuing with FIG. 2, one role of keep-alive timer 208 in the present embodiment is 
to prevent tone regenerating module 216 from regenerating a DTMF tone for an extended 
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length of time, for example, when an end-of-event packet for the digit is not received by 
DTMF relay module 206. To this end, each time that tone regenerating module 216 begins 
regenerating a new DTMF digit, processor 210 sets keep-alive timer 208 to expire after a 
configurable period, which can be, for example, 200 msec. If an end-of-event packet for the 
digit is not received during this period (i.e., prior to the expiration of keep-alive timer 208), 
then processor 210 may signal tone regenerating module 216 to stop the tone when keep-alive 
timer 208 expires. In one embodiment, processor 210 may restart keep-alive timer 208 each 
time a keep-alive packet for the digit is received before keep-alive timer 208 expires. It 
should be noted that processor 210 may signal tone regenerating module 216 to discontinue a 
tone in the event that an end-of-event packet for the digit arrives at DTMF relay module 206 
prior to the expiration of keep-alive timer 208. Moreover, once keep-alive timer 208 has 
expired and tone regenerating module 216 has stopped the tone, all subsequent packets, 
including keep-alive packets, arriving at DTMF relay module 206 for that particular digit may 
be dropped. In this manner, situations wherein a DTMF tone may be regenerated indefinitely 
due to the loss of end-of-event packets, for example, can be avoided. 

Also shown as part of DTMF relay module 206 is tone on/off clock 210, which 
Sanctions as a timer to make certain that the minimum tone on/off time requirements for 
proper DTMF tone recognition by a receiving device are properly met. Thus, each time tone 
regenerating module 216 begins regenerating a new DTMF digit, processor 210 can signal 
tone on/off clock 212 to begin tolling. Tone on/off clock 212 can be set to a desired length of 
time not less than the minimum tone duration required for proper DTMF recognition by a 
receiving device. For example, tone on/ofF clock 212 may be set to expire after 50 msec 
following the start of a new tone by tone regenerating module 216. During this interval 
processor 210 may ignore end-of-event packets and other tone-termination indicators (for 
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example, as indicated by the packet's duration field), for the digit that may be received by 
DTMF relay module 206. As a result, tone on/ofF clock 212 prevents tone regenerating 
module 216 fi-om regenerating a tone for too short a duration. 

Tone on/ofF clock 212 can also be utilized to ensure that the time interval (i.e., the 
"ofF-time") between successive digits regenerated by tone regenerating module 216 is 
adequate, such that the minimum ofF-time interval required for detecting two separate DTMF 
tones is met. For example, for this purpose, tone on/oflf clock 212 may be set to expire 50 
msec after tone regenerating module 216 stops the leading tone. The next DTMF digit 
queued in protected buffer 214, if any, is not sent to tone regenerating module 216 until tone 
on/ofF clock 212 expires. Thus, information regarding start of tone and other tone-initiating 
indicators carried by the packet for the trailing digit may be ignored in order to ensure that 
regeneration of successive DTMF tones satisfy the requirements for proper DTMF 
recognition. 

Referring now to FIG. 3, DTMF relay method 300 illustrates the processing of NTE 
packets in accordance with one embodiment of the present invention. More particularly, 
DTMF relay method 300 illustrates how DTMF relay module 206 in FIG. 2 may proces 
packets arriving ft-om packet network 202. As shown in FIG. 3, DTMF relay method 300 
begins at step 312 where an NTE packet is received by DTMF relay module 206. Once the 
packet has been received, the NTE payload is analyzed by processor 210. Next, at step 314, 
processor 210 determines whether the packet is carrying a DTMF digit or some other type of 
NTE payload by analyzing the packet's event field. As stated above, digits 0 through 15 have 
been reserved for the sixteen DTMF digits. Thus, if the event field is greater than fifl;een, it 
would indicate that the packet's payload is non-DTMF, and DTMF relay method 300 
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continues to step 316. If the event field is not greater than fifteen, then DTMF relay method 
300 proceeds to step 320. 

At step 316, the packet's timestamp is compared to the timestamp of a previously 
received packet or ReceivedTimestamp, If the packet's timestamp is the same as the 
5 ReceivedTimestamp, it would indicate that the packet is a redundant packet carrying the same 
payload as the previously received packet. On the other hand, if the packet's timestamp is 
different from the ReceivedTimestamp, it would indicate that the packet is not a redundant 
packet, but is instead carrying a new NTE. Thus, if processor 210 determines at step 316 that 

^ the packet's timestamp is the same as the ReceivedTimestamp, then the ReceivedTimestamp 

O 

S 10 does not have to be updated, and DTMF relay method 300 returns to step 3 12 where the next 
iji packet can be received and processed. However, if the packet's timestamp is different from 

^1 the ReceivedTimestamp, then the ReceivedTimestamp is updated and reset to the packet's 

Q timestamp at step 318, after which step DTMF relay method 300 returns to step 3 12. 

Til Referring again to step 3 14, if the event field for the packet is not greater than fifteen, 

^jS 15 thus indicating that the packet is carrying a DTMF payload, then DTMF relay method 300 
proceeds to step 320, where processing of packets carrying DTMF digits continues. At step 
320, processor 210 compares the packet's timestamp with the ReceivedTimestamp, and if the 
packet's timestamp is the same as the ReceivedTimestamp, it would indicate that the packet is 
carrying the same DTMF digit as the DTMF digit carried by a previously received packet, 
20 DTMF relay method 300 would then continue to step 322 where processor 210 determines 
whether the packet's end bit is set to 1, representing an end-of-event packet and indicating 
that the tone should be off If the end bit for the packet is found to be "1", then DTMF relay 
method 300 continues to step 324 where processor 210 signals tone regenerating module 216 
to stop the tone, on condition that the tone has been regenerated for a sufficient length of 
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time, which can be 50 msec, for example. Processor 210 can utilize tone on/off clock 212, for 
instance, to ensure that tone regenerating module 216 has regenerated the tone for at least 50 
msec before signaling tone regenerating module 216 to turn off the tone. Thus, DTMF 
recognition by a receiving device is improved significantly, since all DTMF digits that are 
regenerated by tone regenerating module 216 satisfy the duration requirements for proper 
recognition. Next, DTMF relay method 300 then returns to step 3 12. 

However, if it is determined at step 322 that the packet's end bit is "0", it would 
indicate that the packet is a keep-alive packet, and DTMF relay method would proceed to 
step 326. At step 326, processor 210 can restart keep-alive timer 208 if keep-alive timer 208 
has not expired for the digit being regenerated. Following, DTMF relay method 300 returns 
to step 312. 

Returning now to step 320, if processor 210 determines that the packet's timestamp is 
not the same as the ReceivedTimestamp, processor 210 may determine the packet is carrying 
a new or non-redundant DTMF digit. At this point, DTMF relay method 300 would proceed 
to step 328 where processor 210 determines whether protected buffer 214 is fiilL If protected 
buffer 214 is fiill, the packet may be dropped at step 330, and DTMF relay method 300 
returns to step 312 where another NTE packet can be received and processed. 

On the other hand, if protected buflfer 214 is not full, then DTMF relay method 300 
continues to step 332 where the DTMF digit from the packet is added to protected buffer 
214. Next, at step 334, processor 210 analyzes the packet's end bit to determine whether it is 
"1" (i.e., that the packet is an end-of-event packet). If the end bit is not indicative of an end- 
of-event packet, then the packet is carrying either a new tone or a keep-alive payload, and 
thus, DTMF relay method continues at step 336 where the packet's DTMF digit is sent to 
tone regenerating module 216 for regeneration after a sufficient length of time (e.g., 50 msec), 
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has elapsed since tone regenerating module 216 stopped the previous tone to ensure a proper 
interdigit delay. For example, processor 210 can utilize tone on/ofF clock 212 to monitor the 
elapsed time since the previous tone stopped being regenerated prior to sending the next digit 
from protected buffer 214 to tone regenerating module 216 for regeneration. Accordingly, 
DTMF recognition by a receiving device can be enhanced in this manner, because an adequate 
length of time is allowed to elapse before successive DTMF digits are regenerated. Also at 
step 336, processor 210 can start keep-alive timer 208 at the same time the next DTMF digit 
is sent to tone regenerating module 216 for regeneration. DTMF relay method 300 then 
continues to step 340. 

If at step 334 it is determined instead that the packet's end bit is "1", it would indicate 
that the packet is an end-of-event packet, and DTMF relay method 300 would proceed to step 
338. For example, the first packet arriving at DTMF relay module 206 indicative of a "new" 
digit may also simultaneously indicate an end-of-event packet, when all previous packets for 
that digit, such as start-of-tone and keep-aUve packets, have been lost. At step 338, the 
DTMF digit is sent to tone regenerating module 216 for regeneration after a sufficient length 
of time has elapsed since the preceding tone was turned off. Again, processor 210 can utilize 
tone on/ofF clock 212 to track the elapsed time. Further, at step 338, tone on/off clock 312 
can also be utilized to ensure that, once regeneration of the DTMF digit begins, it is 
regenerated for at least a sufficient duration to satisfy the requirements of DTMF recognition 
by a receiving device. For example, the duration can be set to 50 msec. DTMF relay method 
300 then continues at step 340. At step 340, the ReceivedTimestamp is updated by setting it 
equal to the packet's timestamp. DTMF relay method 300 then returns to step 312. 

In one embodiment, DTMF tone relay module 206 can be configured to receive and 
process packets carrying more than one NTE event. For example, under the IETF format 
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(i.e., RFC2833), a packet can contain multiple NTE events, including DTMF and other types 
of events representable as tones. According to such embodiment, processor 210 analyzes the 
contents of a packet most notably the characteristic of each event carried by the packet - in 
order to determine whether any of the events is a DTMF digit. Further, based on the packet's 
timestamp and the timestamp offset for each event in the packet, processor 210 can determine, 
for instance, whether a DTMF digit is on, is being "kept-alive," or is off The information that 
processor 210 derives from the packet may also be used to establish which DTMF digits 
should be placed in protected buffer 214, as well as the proper sequence of digit placement 
into protected buffer 214. DTMF digits placed in protected buffer 214 can then be 
sequentially sent to tone regenerating module 216 for regeneration. According to this 
embodiment, processor 210 can utilize keep-alive timer 208 to limit the duration of tone 
regeneration to 200 msec, for example, in instances where an end-of-event packet for a digit is 
not received. Also, processor 210 can utilize tone on/off clock 212 to manage the 
regeneration of DTMF digits by tone regenerating module 216, such that no digit is 
regenerated for less than a desired length of time (e.g., 50 msec), sufficient for a receiving 
device to recognize the DTMF digit. At the same time, tone on/off clock 212 can also be 
used to ensure that successive DTMF digits are not regenerated too closely to one another 
and that the off-time requirements for DTMF detection and recognition are met. In this 
manner, improved DTMF detection is achieved because multiple DTMF digits in a packet are 
properly processed and, when appropriate, buffered for eventual regeneration. Moreover, 
DTMF digit regeneration may be controlled by specific time constraints and parameters such 
that the regenerated DTMF digits can be properly detected. 

According to various embodiments of the present invention, for example, the DTMF 
tone for each digit is regenerated for at least a configurable length of time sufficient to satisfy 
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the requirements for DTMF recognition. Further, an adequate interdigit delay is imposed 
between the regeneration of successive DTMF digits, such that the receiving device can 
properly detect the separation and distinguish successive digits. Even further, a mechanism is 
introduced to reduce the impact of packet lost by, for example, limiting the length of time a 
digit is regenerated even when end-of-event packets are not received. 

The methods and systems presented above may reside in software, hardware, or 
firmware on the device, which can be implemented on a microprocessor, digital signal 
processor, application specific IC, or field programmable gate array ("FPGA"), or any 
combination thereof, without departing fi-om the spirit of the invention. Furthermore, the 
present invention may be embodied in other specific forms without departing from its spirit or 
essential characteristics. The described embodiments are to be considered in all respects only 
as illustrative and not restrictive. 
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